1. Technical Field
The present invention relates generally to the field of computer software and, more particularly, to a method, system, and apparatus for controlling and distributing software development environments that are fully and correctly configured and tuned to address the various roles developers, test teams, and management, and others play in the process of developing software applications.
2. Description of Related Art
A continual problem with software development is the need to control and distribute environments that are fully and correctly configured. The source code of an application is generally understood to define an application, but a pragmatic view would have to also include in this application definition a host of other software, including the operating system, compilers, tools, directory structures, debuggers, and configuration settings necessary to be effective in developing, compiling, testing, and using the application. When developing large applications, the various roles begin to require different tools, and structures. When development teams are large, these environments, tuned to support each role, must be distributed to all the team members. This process is currently a manual, complex, and error prone effort.
The complexity of managing these environments and the frequently updated application images development requires leads to a steep learning curve as developers must come up to speed with the configurations a given development effort uses, its source tree, state of development, and other structures and procedures. Usually the developer must construct their own development environment using imperfect instructions from a host of sources for each tool used. While this does work, it costs the development effort a significant amount of time, and produces odd effects as differences in environments produce different behaviors which must be identified and understood.
The source code for an application provides an incomplete definition from which the application is built. The missing pieces include the tools, build procedures, and environment configuration for building the application. Most companies today archive not only the source code for applications they develop, but also include every tool, operating system, editor, documentation, debuggers, test data and programs, and other software used in conjunction with development, debugging, testing, and deploying the application. Usually there is an attempt to document the use and mindset behind development and configuration decisions as well. Yet this is an imperfect approach, since the ad hock nature common in software development insures that custom environments used by each developer will be quite different from the environment reconstructed from such an archive.
These problems can be reduced when software developers utilize integrated development environments (IDEs). These environments integrate most of the common and basic tools of software development into one application. This integration reduces the effort required to set up a development environment, insures a standard platform from which the application is developed, and better supports the ability to archive a working development environment. However, for the production of builds and for testing purposes, the use of command line tools such as makefiles and commandline compilers are preferred. This is because integrated development environments do not have a simple, standard interface or mechanism that allows the automated generation of standard builds and revisions. Standard source code control programs also work best when applications are defined by a set of directories and files. Therefore, the usual approach is to export and import source out of and into the IDE to support most of the software development activities that are not strictly related to software development and debugging. Developing and managing the procedures for supporting these different views is inconvenient, and differences in commandline compilers and debuggers and those of the IDE can lead to bugs that are difficult and time consuming to detect and fix.
Software development is also a rather complex process where pieces need to be designed, developed, documented, and tested. As a feature moves through this process, it exists in very different forms. This process may include steps where a feature is proposed, specified, designed, implemented, debugged, tested, folded into the standard build, and included in a released product. At each step, the feature may exist in very different forms, and take the focus of different members of the development team. This is a workflow management problem where the feature under development can be rather fluid, and difficult to understand and define. These difficulties result in development processes that are manual and complex because defining what is required to move a feature from one team member to the next may be different for each feature and for each boundary crossed. Therefore, there is a need to provide a method, system and apparatus that provides a complete definition of an application, the roles supported in this application's development, and definition of the environment required to support each role, and the representation of the application within each role. Developers need an automated process for handing a feature to the test team. All team members need to be able to select a given build, and have delivered the view of that build their job requires. The Build team needs a completely automated facility for producing the versioned build for the quality assurance team. The use of IDEs needs to be supported by automated processes for the development team.